\section {Graphical User Interface}
\label{gui}
As with all graphical applications, web or desktop-based, the GUI, being the only point of contact of the user with the application, is an integral part of the system. We wanted to provide a simple and intuitive experience for the user, similar to existing online social network websites. By coming across an already familiar way of interacting with a system, the user will become an \emph{``expert''} user much faster, which will then allow for greater productivity and emotional attachment to the software.

\subsection {Prototyping a solution}

Prior to prototyping the GUI, we first identified the core actions that the user should be able to perform with the system, as well as elements that need to persist on the interface. We came up with the following:

\begin{itemize}

\item{Viewing recommendations, inspecting the social network and editing one's profile are the three core actions identified.}
\item{The system will follow a two-level hierarchy structure. Three main categories, each reflecting one of the core actions, will comprise the top navigational elements, with each one having a number of subcategories.}
\item{Since our recommender is community based, a space for showing a random subset of the user's friends is needed. A quick link for viewing all of their friends should be provided as well. }
\item{The ability of \emph{``liking''} a page, can also serve as a bookmarking feature thus a space for the user to view all or a subset of their liked pages would be a useful addition.}

\end{itemize}

The initial designs were pen-and-paper and were created and evaluated early in the project cycle. Once agreed, a wireframe prototype was then born, shown in Figure ~\ref{fig:figure1}.

\begin{figure}[H]
  \label{fig:figure1}
  \centering
  \includegraphics[height=4.88in]{resources/wireframe.pdf}                
  \caption{A wireframe prototype.  \label{fig:figure1}}

\end{figure}

\subsection {Designing for performance}

Due to the nature of our application, there are some actions that come with a considerable amount of server latency. For example, since the recommendations come from an external semantic source (DBpedia), the response time of a such request to the server is significantly higher than of a normal request due to the overhead of a further request to the DBpedia endpoint. 

Since there is no way of significantly reducing latency when an external request is needed, we designed our interface to utilise asynchronous loading as much as possible. To achieve that, we used AJAX requests for loading specific parts of the interface, whilst the rest are kept in a common layout, as described in our MVC implementation in Section~\ref{analysis_design}.  

Loading up the interface in such a way, we benefit from three major advantages:

\begin{itemize}

\item{The common parts in the layout are cached, so they load up instantaneously. We also avoid unnecessary HTTP requests to reload the whole page when navigating the sub categories. }
\item{The user sees feedback on their screen very fast, and we thus adhere by a very important usability principle -  \emph{the status of the system should be visible at all times.}}
\item{When multiple requests to external endpoints are needed, for example when viewing recommendations based on one's profile where requests to the DBpedia, YouTube and Last.fm endpoints are required, they are executed in parallel and thus the loading time is really shortened.}

\end{itemize}

The only downturn of this implementation is a higher level of complexity in the code as one has to deal with creating and managing a number of AJAX request as well as updating the parts in the interface when the requests return a response.

\begin{figure}
  \label{fig:figure2}
  \centering
  \includegraphics[width=115.01mm,height=19.05mm]{resources/statschrome.png}                
  \caption{Loading times with the common parts cached. You will notice that the document loads up in 1.33 seconds thus the user receives the page very fast. XHR shows AJAX requests. According to these metrics, the user received recommendations for all Articles, Music and Videos after 5.33 seconds and then another AJAX request to fetch the descriptions for the Articles filled the 6.15 seconds to load up the page fully.}
\end{figure}

\subsection {Look and Feel}

\textbf{Colour scheme} We tried to create a forest-like coloured scheme for our web application, since it is named after a squirrel which lives in the woods. The blue header, one might say, represents the sky where as the light green of the main layout denotes the trees. We also avoided using black in our design, and substituted it with shades of grey to provide for less strain in the eyes.

\textbf{Elements} We chose to make elements like input boxes and buttons unusually big, as opposed to the minimalistic general look and feel of the application. It serves as a good effect to eliminate any doubt for the user on where to click or where to write.

\subsection{Further improvements}

We believe our GUI serves as a good and easy-to-use point of contact of the user with our application. Further improvements are possible, one of those being that due to the limited amount of time, the interface is not fully cross-browser compatible. It abides by the Web standards, but lacks all the hacks needed to make it work in all browsers.